home *** CD-ROM | disk | FTP | other *** search
- Path: chronicle.mti.sgi.com!austern
- From: "ian (i.) willmott" <willmott@bnr.ca>
- Newsgroups: comp.std.c++
- Subject: Re: Generic Object Callbacks
- Date: 04 Mar 1996 12:32:54 PST
- Organization: Northern Telecom
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <4hfjq6$7ko@bcarh8ab.bnr.ca>
- References: <4h9ii0$3mlq@news-s01.ny.us.ibm.net>
- NNTP-Posting-Host: isolde.mti.sgi.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Original-Date: Mon, 4 Mar 1996 20:28:54 +0000
- Content-Identifier: Re: Generic O...
- X-Mailer: Mozilla 1.1 (X11; I; HP-UX A.09.05 9000/720)
- X-Url: news:4h9ii0$3mlq@news-s01.ny.us.ibm.net
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMTtTiky4NqrwXLNJAQF4OwH/ZwwUpJZQVXh8MLBWNRf7laa62scRp+iz
- rYDCSAOGT/pIyQSxWknKwSmmgZZm+X6brMJPFHPkDorU8Dd0nJQ88A==
- =bdGH
- Originator: austern@isolde.mti.sgi.com
-
- References: <4h9ii0$3mlq@news-s01.ny.us.ibm.net>
-
- hickeyr@ibm.net (Rich Hickey) wrote:
-
- >Having previously considered the suggestion you proposed and forced to solve
- >the problem in current language, and with a lot of experience using a
- >current-language solution, I feel it is actually preferable to the extension
- >you propose in the following areas:
- >
- >A)It is more type-flexible. By that I mean it is possible to produce a
- >callback system that is type-safe, yet tolerant of type differences in the
- >caller/callee signatures that are either implicitly convertible or can be
- >ignored. For example if the caller requires a function to which it can pass
- >an int and from which it expects nothing, using my library it is possible to
- >bind the callback to a function that takes an int and returns an int (return
- >value is ignored), or takes a long and returns void (compiler implicitly
- >converts int->long). Once you get involved with polymorphism this becomes
- >critical: caller passes ptr-to-derived, callee accepts ptr-to-base. Any
- >language extension approach would have the rigidity normally associated with
- >pointers-to-functions, i.e. exactly matching signatures required.
-
- I'm not sure what you mean by this. I've never heard of any requirement
- for "exactly matching signatures" for calls through pointers-to-function.
- As far as I know the matching rules are exactly the same as for ordinary
- function calls. The following code is accepted by Cfront v3.0
- without complaint:
-
- class A {
- int x;
- };
-
- class B: public A {
- int y;
- };
-
- int (*fp)(long,A *);
-
- long func(int i,B *p)
- {
- return(fp(i,p));
- }
-
- The proposed language extension would work the same way. It's true
- that this is illegal (I assume this is what you were referring to):
-
- fp=&func; // never mind the infinite recursion here
-
- However, I don't see why this is a problem. You just declare your
- callback functions to take the most general parameters; in this
- example, (long,A *) instead of (int,B *). The proposed type
- "pointer-to-bound-member-function" is the natural analog for class
- member functions of the existing pointer-to-function type, and will
- be useful in the same contexts.
-
- >B)It is easier to extend; to things like callbacks with stored arguments
- >etc.
-
- How so? Here's the PBMF solution:
-
- class MyCallback {
- int (class::*pbmf)(int,A *); // language extension
- int i;
- A *p;
- public:
- MyCallback((class::*pb)(int,A *),int ii,A *pp):
- pbmf(pb),i(ii),p(pp) {}
- int operator()
- { return(pbmf(i,p)); }
- };
-
- No dynamic allocation, virtual functions, casts to void *, or templates
- (although you could use them if you wanted to) needed. Of course, if this
- extension were adopted, this would not prevent other solutions from being
- used anywhere they were appropriate. For most cases, the built-in datatype
- is more convenient and type-safe.
-
- Ian Willmott
- Bell-Northern Research
- Ottawa, Ontario
- (613)-763-9688
- willmott@bnr.ca
- ---
- [ comp.std.c++ is moderated. To submit articles: Try just posting with your
- newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
- comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
- Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-